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Abstract 

Analysis  of  software  fault  trees  exposes  hardware  and 
software  failure  events  that  can  lead  to  unsafe  sys¬ 
tem  states,  and  provides  insight  on  improving  safety 
throughout  each  phase  of  a  system’s  development.  Al¬ 
though  fault  trees  can  be  pruned  for  low  severity  and 
low  probability  nodes,  few  techniques  exist  for  systemat¬ 
ically  improving  system  safety  by  foeusing  on  eost  anal¬ 
ysis  of  a  system’s  fault  tree  nodes. 

In  this  paper,  we  present  an  algorithm  for  system 
failure  mitigation,  supportive  of  continuous  software 
evolution,  based  on  the  reduetion  of  a  fault  tree  into  a 
polynomial  expression  of  degree  g,  where  g  is  the  num¬ 
ber  of  inputs.  We  combine  cost  functions  that  model  the 
expense  of  improving  component  reliability  into  a  vec¬ 
tor  field  which  provides  a  measurement  of  the  degree  of 
difficulty  of  system  improvement.  The  gradient  of  the 
vector  field  is  evaluated  for  vectors  providing  steep  as¬ 
sent  towards  the  area  of  greatest  safety  improvement, 
which  in  turn  provides  guidance  on  improving  design 
time  system  safety.  We  provide  an  example  application 
of  our  improvement  algorithm,  and  examine  improve¬ 
ment  verification  of  the  resulting  system  modifications. 


1.  Introduction 

In  1955  only  10  percent  of  weapons  systems  required 
software,  but  by  1981  over  80  percent  of  such  systems 
required  software  support  [6].  As  the  number  of  soft¬ 
ware  controlled  systems  expands,  the  issue  of  software 
safety  becomes  an  increasingly  critical  aspect  of  sys¬ 
tem  development.  This  is  especially  true  in  the  fields 
of  aerospace,  astronautics,  and  nuclear  engineering, 


where  many  analog  safety  critical  systems  have  been 
transformed  into  digital  systems  that  provide  greater 
flexibility  of  control  setups,  improved  runtime  efficien¬ 
cies,  and  reduced  operating  costs.  However,  the  down¬ 
side  of  transitioning  to  digital  systems  includes  the  dif¬ 
ficulty  of  verifying  the  reliability  of  the  software  system. 

Despite  these  issues,  software  control  systems  have 
been  introduced  to  many  hazardous  systems  including 
nuclear  power  plant  controls,  aviation  guidance  sys¬ 
tems,  and  weapons  systems.  In  such  systems,  the  use 
of  software  has  been  justihed  through  the  large  number 
of  benefits  such  as  flexible  programming,  increased  ca¬ 
pability,  greater  reusability,  and  decreased  deployment 
costs.  The  only  alternative  is  an  inflexible  hardware- 
only  system  which  must  be  redesigned  for  each  new 
system  or  major  system  change  and  tends  to  be  ex¬ 
pensive.  Another  concern  with  the  increased  role  of 
software  control  systems  is  that  the  fast  paced  environ¬ 
ments  in  which  they  run  precludes  manual  intervention 
and  require  automatic  failover  to  backup  systems  [6]. 
While  reliability  in  general  is  an  important  concern  in 
the  software  control  systems,  safety  is  highlighted  as 
one  part  that  is  required  before  software  systems  can 
completely  replace  hardwired  systems. 

2.  Background 

In  this  section  we  review  work  related  to  our  research 
area,  discuss  system  safety  versus  system  reliability, 
examine  cost  functions  as  a  tool  for  predicting  the  cost 
of  system  improvement,  and  explore  fault  tree  concepts 
relevant  to  our  safety  improvement  algorithm. 

2.1.  Related  Work 

Current  work  focusing  on  software  system  safety  in¬ 
volves  development  of  more  accurate  causal  models 


than  the  traditional  accident-oriented  models  in  use 
today.  Efforts  such  as  Leveson’s  work  on  a  system- 
theoretic  approach  to  modeling  safety  in  software¬ 
intensive  systems  use  systems  theory  approaches  to 
model  accidents  resulting  from  component  interaction 
rather  than  individual  component  failure  [5,  1,  4]. 
Leveson’s  approach  is  similar  to  our  work  in  its  focus 
on  the  composite  causes  leading  to  a  system  failure,  but 
unlike  our  approach,  focuses  on  post-accident  analysis 
rather  than  design  time  safety  improvement. 

Our  work  is  similar  to  Sullivan’s  approach  to  con¬ 
verting  fault  trees  into  combinatorial  representations 
[9].  However,  Sullivan’s  approach  requires  selectively 
reverse  engineering  a  specification  from  which  well- 
formed  inputs,  as  well  as  input  from  an  oracle,  are 
derived,  and  yields  a  large  test  suite  that  covers  all 
inputs  up  to  a  given  size.  With  our  approach,  the  in¬ 
put  space  is  made  manageable  via  the  use  of  a  cost 
function  vector  field,  allowing  a  greatly  reduced  state 
space  from  which  to  select  improvement  to  meet  the 
targeted  safety  goal  of  the  fault  tree’s  root. 

Finally,  our  work  is  similar  to  Coppit’s  effort  [2] 
on  evaluating  the  cost  effectiveness  of  developing  and 
validating  complex  safety-critical  systems  through  dy¬ 
namic  fault  tree  analysis  of  fault- tolerant  systems  [3]. 
However,  where  Coppit  focuses  on  the  specification  am¬ 
biguity  regarding  the  simultaneous  occurrence  of  de¬ 
pendent  failure  events,  our  work  focuses  on  the  failure 
probability  of  components  leading  to  a  specific  hazard 
at  the  root  of  the  fault  tree  regardless  of  any  failure 
simultaneity  [11]. 

2.2.  Safety  vs.  Reliability 

Safety  and  reliability  are  two  closely  related  terms 
when  considering  software  systems.  While  it  is  often 
true  that  a  safe  system  is  also  a  reliable  system,  the 
inverse  does  not  necessarily  hold  since  system  speci¬ 
fications  dictate  the  difference  between  a  safe  system 
and  a  reliable  system.  If  the  specifications  include  the 
necessary  safety  requirements,  then  a  system  which  is 
reliable  will  also  be  safe.  Since  this  is  often  not  true, 
the  differentiation  of  safe  and  reliable  is  required  [7] . 

The  reliability,  rather  than  safety,  of  individual  com¬ 
ponents  of  a  system  are  typically  considered,  because 
it  is  often  assumed  that  components  are  simple  enough 
to  be  viewed  as  a  basic  input.  If  a  component  is  too 
complicated,  or  could  be  a  safety  concern,  then  it  is  no 
longer  viewed  as  a  black  box.  In  this  case,  the  compo¬ 
nent’s  fault  tree  is  integrated  into  the  system  fault  tree 
forming  a  composite  tree  that  can  accommodate  failure 
probabilities  for  both  the  hardware  and  software  of  a 
system. 


2.3.  Cost  Functions 

Any  design  change,  component  improvement,  or 
component  redesign  has  costs  attached  to  it  which  can 
be  used  to  yield  cost  functions  describing  how  diffi¬ 
cult  or  costly  the  changes  are.  Without  an  accurate 
cost  function,  the  process  of  making  a  design  safer  will 
result  in  an  over-designed,  probably  over-budget  sys¬ 
tem.  Although  cost  functions  can  combine  all  possible 
costs  (such  as  retooling  costs,  redesign  costs)  in  terms 
of  some  quality,  we  consider  cost  functions  exclusively 
from  the  perspective  of  failure  rate  quality.  It  should 
be  noted  that  the  quality  chosen  impacts  the  character¬ 
istics  of  the  cost  function  including  range,  asymptotes, 
and  slope.  A  cost  function  for  failure  rate  will  have  a 
positive  asymptote  at  x  =  0  and  continue  to  x  =  oo. 
Figure  1  shows  a  representative  cost  function  for  failure 
rate.  The  x-axis  of  Figure  1  is  the  failure  rate  of  the 
system.  As  expected  it  grows  in  an  asymptotic  fashion 
as  the  failure  rate  approaches  0.  The  y-axis  represents 
the  relative  difficulty  of  reducing  the  failure  rate.  Cost 
function  plots  such  as  that  shown  in  Figure  I  can  be 
used  as  a  comparison  with  other  component  cost  func¬ 
tions. 
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Figure  1.  Representative  Cost  Function 

In  order  for  a  cost  function  to  be  used  to  predict 
how  much  work  is  required  for  an  improvement,  there 
must  be  a  way  to  infer  a  measurement  unit,  such  as 
man-hours,  from  the  function.  Such  inference  requires 
a  reference  function  serving  as  a  scaled  version  of  the 
component  cost  function  such  that  precisely  how  many 
man-hours  are  required  to  improve  that  component 
from  a  known  initial  value  to  a  predefined  final  value  is 
known.  For  software  development  companies  operat¬ 
ing  at  CMM  level  3  or  higher,  such  reference  functions 
may  be  reliably  available  from  measurements  and  met¬ 
rics  gathered  from  previous  projects  [8] .  For  companies 
without  such  references,  a  less  precise  approximation  or 
educated  guess  may  be  substituted  with  a  correspond- 


ing  reduction  in  confidence  in  the  reference  function 
accuracy.  The  value  of  the  integral  of  the  cost  function 
between  those  two  points  then  can  serve  as  the  conver¬ 
sion  factor  between  the  integral  of  the  cost  function  and 
man-hours  to  complete  the  work.  An  example  of  how 
the  conversion  works  can  be  found  in  section  4.3.  Fig¬ 
ure  2  shows  a  representative  calibration  cost  function. 
The  shaded  area  represents  the  integral  of  the  function 
that  is  equal  to  a  known  quantity  of  man-hours. 


Figure  2.  Example  Calibration  Cost  Function 


2.4.  Fault  IVees 

Fault  trees  are  interdisciplinary,  finding  application 
for  both  hardware  and  software  systems  in  many  engi¬ 
neering  disciplines,  including  aerospace,  astronautics, 
and  nuclear  engineering.  Fault  trees  originated  at  Bell 
Labs  in  the  1960s  in  support  of  the  U.S.  Air  Force’s 
Minuteman  Missile  Program  [10] .  Fault  trees  are  com¬ 
posites  of  fundamental  entities  known  as  events  and 
gates,  which  form  the  nodes  and  connections  of  the 
tree.  The  root  of  a  fault  tree  is  the  pre-defined  haz¬ 
ard  event  which  the  designer  of  the  tree  seeks  to  either 
prevent  or  minimize  the  probability  of  occurring.  A 
hazard  event  is  any  event  in  a  system  that  can  cause  a 
variety  of  undesirable  results  such  as  loss  of  life,  equip¬ 
ment  loss,  unacceptable  loss  of  functionality,  or  unde¬ 
sirable  operating  conditions.  The  leaves  of  the  tree 
represent  the  fundamental  events  (inputs)  to  the  sys¬ 
tem.  The  root  and  leaves  are  connected  by  a  series 
of  intermediate  events  through  Boolean  operators  as 
shown  in  Figure  3.  In  a  fault  tree,  because  the  focus  of 
the  tree  is  on  the  probability  of  failure  rather  than  the 
probability  of  success.  Boolean  true  is  defined  some¬ 
what  counter-intuitively  as  the  failure  of  a  node  and 
Boolean  false  is  the  success  of  a  node.  Because  inter¬ 
mediate  events  are  themselves  Boolean  expressions,  the 
entire  tree  can  be  expressed  as  a  composite  Boolean  ex¬ 
pression  that  can  be  simplified  using  straight-forward 


algebraic  manipulations.  When  the  probability  of  the 
leaf  elements  are  inserted  into  the  Boolean  expression 
describing  the  system,  a  probability  of  occurrence  can 
be  determined  for  the  specified  hazard.  For  all  but  the 
simplest  systems,  computing  the  probability  of  occur¬ 
rence  is  a  non-trivial  task  because  of  the  computation 
of  the  conditional  probabilities  at  each  node. 


Figure  3.  Example  Fault  Tree 

In  Figure  3,  the  leaf  nodes  are  labeled  d,  e,  f,  and 
g;  and  the  internal  nodes  are  a,  b,  and  c.  In  order 
for  node  b  to  enter  a  failure  state,  both  nodes  d  and  e 
must  fail,  however  for  node  c,  either  nodes  f  or  g  can 
fail  to  cause  the  system  to  enter  a  failure  state.  Node 
a  is  similar  to  node  c  in  that  either  nodes  b  or  c  can 
fail  to  create  a  failure  condition.  When  node  a  is  in 
a  failure  condition,  the  hazard  described  by  the  fault 
tree  occurs. 

In  compute  the  probability  of  a  fault  tree  entering 
a  hazard  state,  we  must  consider  equations  for  AND 
or  OR  node  systems.  Equation  1  is  for  an  AND  node 
system  such  as  in  Figure  4  and  the  equation  2  is  for 
an  OR  node  system  such  as  in  Figure  5.  In  equation  1 
the  failure  probability  of  the  two  children,  a  and  b,  are 
multiplied  together  because  the  probability  of  an  AND 
system  requires  both  two  fail.  Since  an  OR  system  has 
the  opposite  probability  relation  of  an  AND  system  the 
minus  terms  are  required  to  be  able  to  use  the  same 
type  of  input  probability  terms  [10] . 


a  =  be 

(1) 

(2) 

3.  Improvement  Algorithm 

In  this  section,  we  present  an  algorithm  for  improv¬ 
ing  the  structure  of  a  fault  tree  in  a  manner  that  im¬ 
proves  (decreases)  the  probability  of  occurrence  of  the 
hazard  at  the  tree  root.  The  prerequisites  of  the  im¬ 
provement  algorithm  requires:  that  a  fault  tree  exists 
to  describe  how  a  hazard  can  occur,  the  failure  prob¬ 
ability  of  every  component,  and  the  goal  failure  prob¬ 
ability,  G,  are  known  or  can  be  approximated.  The 
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Figure  6.  Sample  Vector  Field 


Figure  5.  OR  probability  relationship 

improvement  algorithm  is  based  on  the  reduction  of 
any  fault  tree  into  a  polynomial  expression  of  degree 
g,  where  g  is  the  number  of  inputs,  by  a  post  order 
traversal  of  the  fault  tree.  For  any  one  value  of  P  there 
are  an  infinite  number  of  sets  of  inputs.  The  objective 
of  our  algorithm  is  to  pick  a  unique  set  of  inputs  to  P, 
such  that  P  is  equal  to  a  goal  value.  In  order  to  se¬ 
lect  the  unique  set  of  inputs  in  this  manner,  additional 
information,  such  as  cost  functions,  is  required. 

Many  hardware  components  have  cost  functions 
that  describe  how  expensive  (in  man-hours)  it  is  to 
improve  the  reliability  of  the  components.  Likewise, 
software  components  typically  have  historical  data,  or 
approximations,  that  can  hll  the  role  of  cost  functions 
in  our  algorithm.  The  combination  of  the  cost  func¬ 
tions  for  all  the  components  yields  a  vector  held,  F, 
in  which  each  dimension  of  the  vector  held  is  the  cost 
function  of  a  component.  An  example  is  where  the  cost 
functions  cO,  cl,  c2,  c3,  c4,  c5,  and  c6  would  create  the 
vector  held  <  cO,  cl,  c2,  c3,  c4,  c5,  c6  >.  The  vector  held 
is  negated  in  order  for  the  direction  to  point  towards 
the  area  of  greatest  safety  rather  than  least  safety.  Fig¬ 
ure  6  is  a  vector  held  formed  from  combining  two  cost 
functions.  The  arrows  point  toward  increased  safety. 
The  vector  held  described  in  Figure  6  is  <  >. 

The  size  of  each  arrow  shows  relative  increase  in  diffi¬ 
culty  of  improvement. 

The  gradient  of  V  is  evaluated  at  a  point  p  (where 


p  is  a  point  in  g  dimensional  space),  —  VF(p),  yields  a 
vector  that  has  the  steepest  assent  towards  the  area  of 
greatest  safety. 

The  initially  known  quantities  are  p*,  P(j)i),  V(pi), 
and  the  desired  value  G.  The  object  is  to  hnd  a  pf, 
such  that  P(pf)  =  G.  Starting  at  the  point  p*,  the 
vector  V(j)i)  will  point  towards  the  level  curve  dehned 
hy  P  =  G.  A  scaling  factor,  k,  is  then  used  to  stretch 
the  vector  V(pi)  so  that  it  intersects  the  level  curve 
P  =  G.  The  point  where  kV (p*)  intersects  with  P  =  G 
is  pf.  Using  substitution,  the  polynomial  expression 
P  with  g  unknowns  is  changed  to  have  one  unknown, 
k.  We  call  the  new  polynomial  expression  P^.  An 
example,  based  on  Equation  1,  of  the  substitution  is: 

P{bi,Ci)  =  bfCf 
kV{bi,Ci)  =  k<e,f> 

Pk{bt,  (k)  =  {h  -  ke){(k  -  kf) 

There  will  be  at  most  g  real  roots  of  Pk-  The  real 
root  of  k  that  creates  the  smallest  vector  kV{pi)  such 
that  Pi  +  kV{pi)  yields  a  result  with  in  the  domain  of 
(0  <  p/  <  1).  Once  p/  is  known  it  can  be  compared  to 
Pi  to  determine  the  percent  change  in  the  reliability  of 
each  component. 

The  man-hours  required  to  improve  a  component 
from  its  initial  reliability  to  its  final  reliability  can  be 
found  by  taking  the  integral  of  the  cost  function  for 
that  component  from  the  initial  reliability  to  the  final 
reliability.  The  accuracy  of  the  work  estimate  relies  on 
how  accurately  the  cost  function  models  reality.  For 


companies  that  have  sufficiently  refined  metrics  such 
as  those  found  in  companies  at  CMM  level  3,  the  cost 
functions  may  be  well  defined  [8] .  For  other  companies, 
the  cost  function  may  be,  at  best,  only  an  approxima¬ 
tion. 

4.  Application 

In  this  section,  we  apply  the  improvement  algorithm 
to  a  maintenance  scenario  of  safety  critical  software  in 
which  a  client  has  requirements  related  to  the  overall 
safety  of  the  system,  and  cost  functions  that  can  be 
applied  to  system  components. 

4.1.  Example  Improvement  Scenario 

We  examine  the  scenario  of  a  customer  requesting 
that  additional  features  be  added  to  a  safety  critical 
software  system.  The  customer  specifies  that  the  safety 
of  the  modified  system  can  be  no  worse  than  the  safety 
of  the  original  system.  The  original  system  was  veri¬ 
fied  by  program  proving,  however  due  to  cost  consider¬ 
ations  the  progress  of  program  proving  is  undesirable 
for  the  modified  version.  The  improvement  algorithm 
offers  an  alternative  to  program  proving  in  such  a  case. 

4.2.  Prerequisites 

In  order  to  use  the  improvement  algorithm  in  this 
scenario,  a  few  things  must  be  known.  First,  the  prob¬ 
ability  of  each  hazard  occurring  in  the  initial  system  is 
required.  This  may  involve  the  construction  of  fault 
trees  and  computation  of  each  probability.  Second, 
fault  trees  need  to  be  constructed  for  the  modified  sys¬ 
tem  for  each  hazard.  Third,  the  present  failure  proba¬ 
bility  of  each  of  the  components  must  be  known.  The 
fourth,  and  final  prerequisite,  is  that  cost  functions  be 
available  for  the  improvement  of  all  components.  Table 
1  lists  the  initial  failure  probabilities  of  all  the  variables, 
the  cost  functions,  and  the  desired  failure  probability 
of  the  system. 

4.3.  Verifying  the  Modified  System 

In  order  to  verify  that  the  situation  is  improved 
through  the  application  of  our  improvement  algorithm, 
the  probability  of  each  hazard  occurring  in  the  mod¬ 
ified  system  is  calculated.  Based  upon  these  calcula¬ 
tions,  a  set  of  hazard  conditions  is  created  in  which 
the  modified  system  does  not  meet  the  safety  require¬ 
ments.  The  improvement  algorithm  is  then  executed 
on  the  fault  tree  for  each  hazard  in  the  set.  This  re¬ 
sults  in  a  list  of  components  that  need  to  be  improved 


variable 

value 

variable 

value 

pO 

0.35 

cO 

pi 

0.29 

cl 

p2 

0.41 

c2 

p3 

0.32 

c3 

pA 

0.49 

c4 

p5 

0.25 

c5 

p6 

0.20 

c6 

P 

0.55 

G 

0.3 

Table  1.  Initial  Values 


and  by  what  amount  order  to  meet  the  desired  failure 
probability.  While  the  list  produced  may  not  be  the 
cheapest  possible  solution  it  is  not  an  expensive  solu¬ 
tion. 

The  rest  of  this  section  examines  the  improvement 
process  for  a  single  hazard,  M).  The  fault  tree  in  Fig¬ 
ure  7  represents  all  possible  ways  for  the  software  sys¬ 
tem  to  cause  M).  The  cost  functions  for  each  of  the 
seven  inputs  are  labeled  cO  through  c6.  The  initial  fail¬ 
ure  probabilities  of  each  component  are  similarly  pO 
through  p6.  Node  0,  for  example,  would  have  a  cost  of 
cO  and  a  probability  of  failure  of  pO. 

The  fault  tree  probability  equation,  P,  is  created 
from  Figure  7,  and  is: 

P(p0,pl,p2,p3,p4,p5,p6)  = 

1  _  (1  _(!_(!_ p0)(l-(pl)(p2)))) 

(1  -  (p3)(l  -  (1  -p4)(l  -p5)(l  -p6)))) 

Once  the  probability  of  the  hazard  is  computed  it  can 
be  compared  to  the  desired  probability,  G.  Since  the 
probability  of  hazard  is  greater  than  G  the  next  step 
of  the  algorithm  is  executed  in  which  a  vector  field  is 
created  from  the  seven  cost  functions  such  that: 

V(c0,cl,c2,c3,c4,c5,c6)  = 
^111  1  1  1  1  ^ 
tOA  ’  Toe’  77743’  TTTse  ’  TTTts  ’  TTTss  ’  TTTss  ^ 

The  gradient  of  V  at  the  initial  point 
(p0,pl,p2,p3,p4,p5,p6),  provides  the  direction 
towards  the  desired  failure  probability  curve.  Once 
the  gradient  is  known,  it  is  combined  with  P  to  create 
an  equation  only  in  terms  of  the  scaling  factor  k. 
The  scaling  factor  k,  is  the  smallest  positive  root  of 
Pfc,  in  this  case  k  =  0.083321.  The  scaling  factor  is 
then  substituted  into  individual  component  equations 
to  find  the  failure  probability  of  each  component 
necessary  to  have  the  desired  failure  probability  for 
the  system.  The  failure  probability  of  each  component 


variable 

value 

%  improvement 

pO 

0.22 

37.1 

8.8 

pi 

O.Il 

62.1 

19.9 

p2 

0.29 

29.3 

7.7 

p3 

0.16 

14.7 

pA 

0.34 

12.2 

p5 

0.06 

24.4 

pQ 

0.05 

13 

P 

45.5 

100.7 

Table  2.  Final  Values 


required  to  meet  the  system  requirements  is  shown  in 
Table  2. 

Assuming  that  the  calibrated  cost  function  is  the 
cost  function  cO  and  that  the  integral  of  cO  from  0.7  to 
0.5  is  equal  to  10  man-hours,  the  cost  to  improve  the 
system  can  be  predicted  by  using  this  value  to  convert 
the  integrals  of  the  other  cost  functions.  In  the  case 
of  this  example  100.7  man-hours  would  be  required  to 
improve  the  failure  probability  from  0.55  to  0.3. 

5.  Conclusion 

Analysis  of  software  fault  trees  exposes  hardware 
and  software  failure  events  that  can  lead  to  unsafe  sys¬ 
tem  states,  and  provides  insight  on  improving  safety 
throughout  each  phase  of  a  system’s  development. 
Our  work  represents  a  hrst  step  in  investigating  cost- 
sensitive  methods  of  verifying  safety  critical  software 
systems.  We  presented  an  algorithm  for  system  failure 


mitigation  based  on  the  reduction  of  fault  trees  into 
polynomial  expressions.  Cost  functions  were  applied 
to  the  nodes  of  the  fault  tree  to  identify  nodes  where 
improvement  will  effectively  lead  to  increased  safety  of 
the  system  represented  by  the  fault  tree.  We  provided 
an  example  application  of  our  improvement  algorithm, 
and  examined  improvement  verification  of  the  resulting 
system  modifications. 

Future  work  in  this  area  focuses  on  the  efficiency  of 
the  improvement  algorithm,  which  is  currently  far  from 
optimal.  Areas  where  improvements  could  be  made  in¬ 
clude  the  possible  use  of  stream  functions  to  find  the 
cheapest  path  between  the  initial  and  goal  fault  prob¬ 
abilities  and  the  use  of  Lagrange  multiplies  to  avoid 
the  scalability  issue  raised  of  finding  the  roots  of  high 
degree  polynomials.  Other  future  work  includes  de¬ 
veloping  the  improvement  algorithm  from  a  research 
project  into  a  tool  that  can  be  readily  used  by  software 
developers. 
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